Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?

["David M Williams" <david_williams@xxxxxxxxxx>]

Actually, there was yet another thing I
should have mentioned. This topic of "improve input to the aggregation
build" has been discussed in bug 419746. 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=419746

I suggest further discussion on this
topic or this new requirement take place there. 

Thanks 




From:      
 David M Williams/Raleigh/IBM@IBMUS
To:      
 stepper@xxxxxxxxxx,
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>, 
Date:      
 01/08/2016 02:04 PM
Subject:    
   Re: [cross-project-issues-dev]
Enforce Gerrit for Simrel?
Sent by:    
   cross-project-issues-dev-bounces@xxxxxxxxxxx

---

I think this topic has been well discussed,
but thought I would add one thing since no one has commented on it. 

It is not just listing exact versions and/or pointing to a simple repository
-- but also that "the b3aggrcon file must change for every new contribution".
In other words, the requirement would not be satisfied by someone merely
pointing a simple repository such as "latest". Even if it had
only "one version" of each feature and bundle, this is one of
the cases of "changing repository contents in the middle of a build"
that we are going to avoid. 

Even if no "perfect test" for it, in the long run, we may implement
our process such that "if the file does not change, we use the contents
we already have" and won't even look at the source repository and
would never get new contributions, if someone was pointing at "one
repository" and not changing the file to point to a unique, simple
repository that had their intended contribution. 

I just wanted to be clear on this aspect of the requirement, as part of
"educating everyone". 

= = == = =

Some have mentioned "tools", and a change to b3 aggegator editor
might indeed be handy. But what others would want even more is something
more "batch oriented" so that they could produce the input file
has part of their build (based on a "template", say, that could
be their previous input?).  And then they may or may not "check
in" that new file (to Gerrit "for master" :),  based
on if that build was declared "good" or not. If anyone has any
tools like this to share, feel free to do so! I recommend getting started
by opening a c-p bug and attaching the tool, and then others could review
and improve if needed. 

= = = = = =  

Thanks, 



 



From:        Eike
Stepper <stepper70@xxxxxxxx>
To:        cross-project-issues-dev@xxxxxxxxxxx,
Date:        01/08/2016
01:14 PM
Subject:        Re:
[cross-project-issues-dev] Enforce Gerrit for Simrel?
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx

---

Am 08.01.2016 um 17:29 schrieb Marc Khouzam:
> I also would not like to have to change versions.
> Changing the URL only allows me to change one line quickly.
> Changing each version of each feature group is more work and more
error prone.
Exactly. I also don't want to look *into* my repos for each contribution
and copy multiple versions around.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



>
> And when speaking about tests, isn't it possible to verify that each
URL is not a composite repo?
>
> ------------------------------------------------------------------------------------------------------------------------
> *From:* cross-project-issues-dev-bounces@xxxxxxxxxxx [cross-project-issues-dev-bounces@xxxxxxxxxxx]
on behalf of 
> Mickael Istria [mistria@xxxxxxxxxx]
> *Sent:* January 8, 2016 11:23 AM
> *To:* cross-project-issues-dev@xxxxxxxxxxx
> *Subject:* Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?
>
> On 01/08/2016 05:15 PM, Eike Stepper wrote:
>> I may misunderstand this fixed version stuff, so I better ask
explicitely. I will not be forced to author exact 
>> feature versions in my contribution files, right?
>> I'm fine with the rule of contributing only fixed content, but
I prefer to achieve that goal with non-changing repos.
>
> The rule currently accepts version ranges with "changing"
repository URL. However, it seems very difficult to write 
> good tests that guarantee that the rule is respected... That's why
I'm trying to push towards the 4-digits version 
> rule as "de-facto standard", since it can trivially be checked.
> From your contributor point-of-view, what makes changing the version
more difficult that changing an URL? In any case, 
> you'll have to make a change in the b3aggrcon file whenever you want
to contribute something new. It seems to me that 
> the extra-cost of changing the version when also changing the URL
is not that high, is it?
>
> Cheers,
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com>
- My Tweets <http://twitter.com/mickaelistria>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev