New plugin : buildtriggerbadge

[mpapo - Michaël Pailloncy]

Hi,

Here is a small plugin showing an icon representing the trigger cause of a build (timer, scm changes or user action) directly in the build history : https://github.com/mpapo/buildtriggerbadge-plugin.git

Can you please fork it ?

Thanks in advance,

Michaël

[nicolas de loof-2]

project forked : https://github.com/jenkinsci/buildtriggerbadge-plugin

2012/9/15 mpapo - Michaël Pailloncy <[hidden email]>

Hi,

Here is a small plugin showing an icon representing the trigger cause of a build (timer, scm changes or user action) directly in the build history : https://github.com/mpapo/buildtriggerbadge-plugin.git

Can you please fork it ?

Thanks in advance,

Michaël

[mpapo - Michaël Pailloncy]

Thank you Nicolas.

Can you give me write rights to this repo ? (id : mpapo)

I can't push on it.

Baptiste Mathus (id : Batmat) has also developed on this plugin. Can you give him write rights too ?

Thanks in advance,

Michaël

2012/9/17 nicolas de loof <[hidden email]>

project forked : https://github.com/jenkinsci/buildtriggerbadge-plugin

2012/9/15 mpapo - Michaël Pailloncy <[hidden email]>

Hi,

Here is a small plugin showing an icon representing the trigger cause of a build (timer, scm changes or user action) directly in the build history : https://github.com/mpapo/buildtriggerbadge-plugin.git

Can you please fork it ?

Thanks in advance,

Michaël

[Baptiste MATHUS-2]

Hi all,

Well, yes, as Michaël explained we're going to be two maintainers for this plugin. 

(As we actually worked separately on our plugin version (without knowing the other had begun), so we ended up merging them before submitting.).

By the way, I've had a look at the plugin contributors wiki pages, but didn't find the information about plugin hosting under jenkinsci github organization:

1. Are we to work on our repo, and sometimes someone having commit rights onto the jenkinsci forked is going to git pull --rebase upstream?
2. Or are we to work directly on the jenkinsci forked version?
3. What else?

Please note we are totally open to work the way you prefer. IMO, it'd be simpler and less work for everyone to just get commit rights on the forked version, and then even wipe out the upstream one (so that people don't potentially get confused). 

But if it's not the way it currently works, no problem.

Just let us know.

Cheers.

2012/9/18 Michaël Pailloncy <[hidden email]>

Thank you Nicolas.

Can you give me write rights to this repo ? (id : mpapo)

I can't push on it.

Baptiste Mathus (id : Batmat) has also developed on this plugin. Can you give him write rights too ?

Thanks in advance,

Michaël

2012/9/17 nicolas de loof <[hidden email]>

project forked : https://github.com/jenkinsci/buildtriggerbadge-plugin

2012/9/15 mpapo - Michaël Pailloncy <[hidden email]>

Hi,

Here is a small plugin showing an icon representing the trigger cause of a build (timer, scm changes or user action) directly in the build history : https://github.com/mpapo/buildtriggerbadge-plugin.git

Can you please fork it ?

Thanks in advance,

Michaël

--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
nbsp;!

[nicolas de loof-2]

You both have been added to the committer team

2012/9/18 Baptiste MATHUS <[hidden email]>

Hi all,

Well, yes, as Michaël explained we're going to be two maintainers for this plugin. 

(As we actually worked separately on our plugin version (without knowing the other had begun), so we ended up merging them before submitting.).

By the way, I've had a look at the plugin contributors wiki pages, but didn't find the information about plugin hosting under jenkinsci github organization:

1. Are we to work on our repo, and sometimes someone having commit rights onto the jenkinsci forked is going to git pull --rebase upstream?
2. Or are we to work directly on the jenkinsci forked version?
3. What else?

As you like. You can move all dev effort on jenkinci, using branches if you need to experiment a few. You also can use it only as a canonical repo and still use your own repo to review each-other changes before pushing. It's all yours, and depends on your maturity and expectations with DVCS :)

 

Please note we are totally open to work the way you prefer. IMO, it'd be simpler and less work for everyone to just get commit rights on the forked version, and then even wipe out the upstream one (so that people don't potentially get confused). 

But if it's not the way it currently works, no problem.

Just let us know.

Cheers.

2012/9/18 Michaël Pailloncy <[hidden email]>

Thank you Nicolas.

Can you give me write rights to this repo ? (id : mpapo)

I can't push on it.

Baptiste Mathus (id : Batmat) has also developed on this plugin. Can you give him write rights too ?

Thanks in advance,

Michaël

2012/9/17 nicolas de loof <[hidden email]>

project forked : https://github.com/jenkinsci/buildtriggerbadge-plugin

2012/9/15 mpapo - Michaël Pailloncy <[hidden email]>

Hi,

Here is a small plugin showing an icon representing the trigger cause of a build (timer, scm changes or user action) directly in the build history : https://github.com/mpapo/buildtriggerbadge-plugin.git

Can you please fork it ?

Thanks in advance,

Michaël

--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
nbsp;!

[mpapo - Michaël Pailloncy]

Ok thanks Nicolas :)

2012/9/18 nicolas de loof <[hidden email]>

You both have been added to the committer team

2012/9/18 Baptiste MATHUS <[hidden email]>

Hi all,

Well, yes, as Michaël explained we're going to be two maintainers for this plugin. 

(As we actually worked separately on our plugin version (without knowing the other had begun), so we ended up merging them before submitting.).

By the way, I've had a look at the plugin contributors wiki pages, but didn't find the information about plugin hosting under jenkinsci github organization:

1. Are we to work on our repo, and sometimes someone having commit rights onto the jenkinsci forked is going to git pull --rebase upstream?
2. Or are we to work directly on the jenkinsci forked version?
3. What else?

As you like. You can move all dev effort on jenkinci, using branches if you need to experiment a few. You also can use it only as a canonical repo and still use your own repo to review each-other changes before pushing. It's all yours, and depends on your maturity and expectations with DVCS :)

 

Please note we are totally open to work the way you prefer. IMO, it'd be simpler and less work for everyone to just get commit rights on the forked version, and then even wipe out the upstream one (so that people don't potentially get confused). 

But if it's not the way it currently works, no problem.

Just let us know.

Cheers.

2012/9/18 Michaël Pailloncy <[hidden email]>

Thank you Nicolas.

Can you give me write rights to this repo ? (id : mpapo)

I can't push on it.

Baptiste Mathus (id : Batmat) has also developed on this plugin. Can you give him write rights too ?

Thanks in advance,

Michaël

2012/9/17 nicolas de loof <[hidden email]>

project forked : https://github.com/jenkinsci/buildtriggerbadge-plugin

2012/9/15 mpapo - Michaël Pailloncy <[hidden email]>

Hi,

Here is a small plugin showing an icon representing the trigger cause of a build (timer, scm changes or user action) directly in the build history : https://github.com/mpapo/buildtriggerbadge-plugin.git

Can you please fork it ?

Thanks in advance,

Michaël

--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
nbsp;!

[Baptiste MATHUS-2]

2012/9/18 nicolas de loof <[hidden email]>

By the way, I've had a look at the plugin contributors wiki pages, but didn't find the information about plugin hosting under jenkinsci github organization:

1. Are we to work on our repo, and sometimes someone having commit rights onto the jenkinsci forked is going to git pull --rebase upstream?
2. Or are we to work directly on the jenkinsci forked version?
3. What else?

As you like. You can move all dev effort on jenkinci, using branches if you need to experiment a few. You also can use it only as a canonical repo and still use your own repo to review each-other changes before pushing. It's all yours, and depends on your maturity and expectations with DVCS :)

OK, thanks a lot.

Well, as read somewhere else, "I [already] crashed and burned. Badly. Multiple times." with Git (©KR).

So, I guess we might consider removing upstream to prevent being unclear about where the reference version of the plugin is.

Git branching + DVCS seems already quite enough when needing to experiment :).

Cheers

--
Baptiste <Batmat> MATHUS - http://batmat.net
Save a tree,

Eat a beaver.

[Baptiste MATHUS-2]

Hi,

The corresponding component is missing on JIRA. I suppose it's not created automatically?

Could it be created or could I get the rights to do it (pluginId=buildtriggerbadge, JIRA username=batmat)?

Thanks a lot.

Cheers

2012/9/18 Baptiste MATHUS <[hidden email]>

2012/9/18 nicolas de loof <[hidden email]>

By the way, I've had a look at the plugin contributors wiki pages, but didn't find the information about plugin hosting under jenkinsci github organization:

1. Are we to work on our repo, and sometimes someone having commit rights onto the jenkinsci forked is going to git pull --rebase upstream?
2. Or are we to work directly on the jenkinsci forked version?
3. What else?

As you like. You can move all dev effort on jenkinci, using branches if you need to experiment a few. You also can use it only as a canonical repo and still use your own repo to review each-other changes before pushing. It's all yours, and depends on your maturity and expectations with DVCS :)

OK, thanks a lot.

Well, as read somewhere else, "I [already] crashed and burned. Badly. Multiple times." with Git (©KR).

So, I guess we might consider removing upstream to prevent being unclear about where the reference version of the plugin is.

Git branching + DVCS seems already quite enough when needing to experiment :).

Cheers

--
Baptiste <Batmat> MATHUS - http://batmat.net

Save a tree,

Eat a beaver.

--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[nicolas de loof-2]

buildtriggerbadge Jira component created for batmat,

but ... your plugin has no bug, has it ?

2012/9/21 Baptiste MATHUS <[hidden email]>

Hi,

The corresponding component is missing on JIRA. I suppose it's not created automatically?

Could it be created or could I get the rights to do it (pluginId=buildtriggerbadge, JIRA username=batmat)?

Thanks a lot.

Cheers

2012/9/18 Baptiste MATHUS <[hidden email]>

2012/9/18 nicolas de loof <[hidden email]>

By the way, I've had a look at the plugin contributors wiki pages, but didn't find the information about plugin hosting under jenkinsci github organization:

1. Are we to work on our repo, and sometimes someone having commit rights onto the jenkinsci forked is going to git pull --rebase upstream?
2. Or are we to work directly on the jenkinsci forked version?
3. What else?

As you like. You can move all dev effort on jenkinci, using branches if you need to experiment a few. You also can use it only as a canonical repo and still use your own repo to review each-other changes before pushing. It's all yours, and depends on your maturity and expectations with DVCS :)

OK, thanks a lot.

Well, as read somewhere else, "I [already] crashed and burned. Badly. Multiple times." with Git (©KR).

So, I guess we might consider removing upstream to prevent being unclear about where the reference version of the plugin is.

Git branching + DVCS seems already quite enough when needing to experiment :).

Cheers

--
Baptiste <Batmat> MATHUS - http://batmat.net

Save a tree,

Eat a beaver.

--
Baptiste <Batmat> MATHUS - http://batmat.net

Sauvez un arbre,
Mangez un castor !

[Baptiste MATHUS-3]

Thanks.

No bug, but improvements idea, or whatever.

I considered using JIRA(s) myself on this id to kind of store some kind of roadmap for improvements.

By the way, is there any recommendation for storing "TODO/roadmap" for a plugin?

2012/9/21 nicolas de loof <[hidden email]>

buildtriggerbadge Jira component created for batmat,

but ... your plugin has no bug, has it ?

2012/9/21 Baptiste MATHUS <[hidden email]>

Hi,

The corresponding component is missing on JIRA. I suppose it's not created automatically?

Could it be created or could I get the rights to do it (pluginId=buildtriggerbadge, JIRA username=batmat)?

Thanks a lot.

Cheers

2012/9/18 Baptiste MATHUS <[hidden email]>

2012/9/18 nicolas de loof <[hidden email]>

By the way, I've had a look at the plugin contributors wiki pages, but didn't find the information about plugin hosting under jenkinsci github organization:

1. Are we to work on our repo, and sometimes someone having commit rights onto the jenkinsci forked is going to git pull --rebase upstream?
2. Or are we to work directly on the jenkinsci forked version?
3. What else?

As you like. You can move all dev effort on jenkinci, using branches if you need to experiment a few. You also can use it only as a canonical repo and still use your own repo to review each-other changes before pushing. It's all yours, and depends on your maturity and expectations with DVCS :)

OK, thanks a lot.

Well, as read somewhere else, "I [already] crashed and burned. Badly. Multiple times." with Git (©KR).

So, I guess we might consider removing upstream to prevent being unclear about where the reference version of the plugin is.

Git branching + DVCS seems already quite enough when needing to experiment :).

Cheers

--
Baptiste <Batmat> MATHUS - http://batmat.net

Save a tree,

Eat a beaver.

--
Baptiste <Batmat> MATHUS - http://batmat.net

Sauvez un arbre,
Mangez un castor !

--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !